The present invention relates to the field of Mobile Satellite Systems (MSS), in particular, enhanced paging techniques and Quality of Service (QoS) establishment in mobile satellite communication systems (MSS).
The majority of terrestrial cellular systems have evolved to Third Generation (3G) systems and beyond with a focus on Internet Protocol (IP) Multimedia services based on Session Initiation Protocol (SIP). SIP is a signaling protocol widely used for creating, managing and terminating sessions, such as voice calls, video conferencing, instant messaging, etc., in an IP based network. In line with the terrestrial evolution, MSS are also evolving to 3G services and beyond. The IP Multimedia Subsystems (IMS) is a key element in the 3G architecture that makes it possible to provide ubiquitous cellular access to all the services provided by the internet, for example, web, multimedia, email, video conferencing to name a few.
3G networks interface with General Packet Radio Service (GPRS) Core Network (CN) to transmit IP packets to external networks such as the internet. GPRS is a packet oriented mobile data service, which is maintained by the Third Generation Partnership Project (3GPP). 3GPP has chosen SIP and the related protocols for session establishment and management. SIP is used for signaling between a user terminal and the IMS as well as between the entities within the IMS.
In contrast to terrestrial cellular system, typical MSS operations require a line of sight (LOS) with a satellite. Typically, when a MSS user is inside a building and there is an incoming call, an enhanced paging called “Alerting” is used to notify user of an incoming call. Alerting is expensive in terms of satellite power needed to reach the users, therefore, there is a desire by MSS operators to use enhanced paging only for specific services such as voice. Since the information about the type of service is indicated inside the SIP message, which is compressed and/or encrypted by IMS elements, GPRS gateway, which is responsible for paging and alerting, cannot read the contents of SIP message. This is further explained with the help of FIG. 1.
FIG. 1 illustrates a typical mobile satellite system 100.
As illustrated in the figure, typical mobile satellite system 100 includes a satellite network 102, a terrestrial mobile network 104, and an IMS Core Network (CN) 106. Satellite network 102 further includes a User Terminal (UT) 116, which is in the coverage region of a satellite beam 108. In this example, UT 116 includes a cell phone device. UT1 116 communicates to a satellite 110 via a communication network signal 154 and to a satellite 112 via a communication network signal 156.
A GPRS gateway consisting of a Radio Access Network (RAN) 120, a Serving GPRS Support Node (SGSN) 122 and a Gateway GPRS Support Node (GGSN) 124 connects IMS CN 106 with UT 116 via satellite 110 or satellite 112.
Terrestrial mobile network 104 further includes a User Equipment (UE) 114, which is in the coverage region of a cell 118. In this example, UE 114 includes a cell phone device. A RAN 126 connects UE 114 to IMS CN 106 via a SGSN 128 and a GGSN 130.
IMS CN 106 is also connected to a telephone 150 via a Public Switched Telephone Network (PSTN) 148.
IMS CN 106 further includes a Proxy-Call Session Control Function (P-CSCF) 132, a Serving-Call Session Control Function (S-CSCF) 134, an Interrogating-Call Session Control Function (I-CSCF) 136, a Media Resource Function Controller (MRFC) 138, a Media Resource Function Processor (MRFP) 140, a Media Gateway (MGW) 142, a Media Gateway Controller Function (MGCF) 144 and a Signaling Gateway (SGW) 146. Note that IMS CN 106 only illustrates components related to SIP signaling in FIG. 1. However, for other applications, IMS CN 106 may include different components. Additionally, all the components of MSS 100 are known in the art; therefore, their functionality is not discussed in detail in this application.
RAN 120 is operable to communicate to satellite 110 via a network signal 158 and to satellite 112 via a network signal 160. RAN 120 is also operable to communicate with SGSN 122.
SGSN 122 is operable to transfer data packets to and from UT 116 within its geographical area. Some of the non-limiting functions of SGSN 122 include packet routing and transfer, authentication and charging functions of GPRS mobiles, mobility management and logical link management. The location register of SGSN 122 stores location information (for example, current cell, current Visitor Location Register) and user profiles of all GPRS users registered with SGSN 122.
GGSN 124 is responsible for sending user packets to external IP based networks and routing packets back to the mobile user. GGSN 124 is operable to convert GPRS packets coming from SGSN 122 into the appropriate Packet Data Protocol (PDP) format and sends them out to corresponding packet data network. GGSN 124 has several functions, including packet inspection for detecting different types for traffic, which can be used for shaping the traffic under different network load conditions. GGSN 124 keeps a record of active mobile users attached to SGSN 122. GGSN 124 is also responsible for policy control, billing and assigning IP addresses to mobile users. When GGSN 124 receives data addressed to a specific user routed through IMS CN 106, it checks if the user is active. For example, if UT 116 is active, GGSN 124 forwards the data to SGSN 122, and if UT 116 is not active, the data are discarded.
RAN 126 is operable to connect to UE 114 via a terrestrial network signal 152, which is part of a Universal Terrestrial Radio Access Network (UTRAN). SGSN 128 is similar to SGSN 122 in operation and GGSN 130 is similar to GGSN 124 in operation.
IMS CN 106 is operable to provide mobility management, session management and transport for IP packet services in addition to functions such as billing and lawful interception.
P-CSCF 132 is the first point of contact for the IMS terminal and is operable to process SIP signaling packets. Some of the non-limiting functions of P-CSCF 132 include subscriber authentication, inspecting all signaling from the IMS terminal, compression and decompression of SIP messages, policy decision function including QoS and generating charging records. QoS profile includes different parameters such as traffic class, bit rate, error rate, transfer delay, etc. to name a few. Traffic class defines nature of traffic—mainly divided into conversational class (voice, video telephony, video gaming), streaming class (multimedia, video on demand, webcast), interactive class (web browsing, network gaming, database access), and background class (email, SMS, downloading).
S-CSCF 134 is the central node of the signaling plane. It is operable to perform session control in addition to being an SIP server. Some of the non-limiting functions of S-CSCF 134 include handling SIP registration, which allows it to bind the user location and the SIP address, inspecting all signaling messages of the locally registered users, providing routing services, enforcing the network operator policies, and deciding which application server the SIP messages will be forwarded, in order to provide their services.
I-CSCF 136 is operable to forward SIP requests or responses to S-CSCF 134. It functions as another SIP function located at the edge of an administrative domain.
MRFC 138 and MRFP 140 together constitute Media Resource Function (MRF), which provides media related functions such as media manipulation and playing of tones and announcements. MRFC 138 is operable to receive information coming from S-CSCF 134 and interpret it to control MRFP 140. MRFP 140 is operable to mix, source or process media streams in addition to managing access rights to shared resources.
MGW 142, MGCF 144 and SGW 146 function as PSTN gateway to communicate with PSTN 148. MGCF 144 is an SIP endpoint and is operable to perform call control protocol conversion. It also controls resources in MGW 142 and interfaces with SGW 146. SGW 146 interfaces with the signaling plane of PSTN 148 and is operable to transform different protocols to pass to S-CSCF 134 via MGCF 144. MGW 142 interfaces with the media plane of PSTN 148 and is part of Media Resources controlled by IMS core functions.
A session initiated from UE 114 to UT 116 goes through IMS CN 106 via UTRAN. Similarly, a session initiated from telephone 150 to UT 116 goes through IMS CN 106 via PSTN 148.
Typically, 3GPP IMS uses SIP based signaling. All the signaling to and from UT 116 goes through P-CSCF 132. Since most of the SIP messages are large, 3GPP recommends that SIP messages between UT 116 and P-CSCF 132 are compressed in order to save over-the-air bandwidth. As a result, gateway between UT 116 and P-CSCF 132, namely RAN 120, SGSN 122 and GGSN 124 will not be able to examine the contents of the signaling message between UT 116 and P-CSCF 132. In this case, the gateway will not be able to identify if the call is for voice, fax or something else, and, hence, cannot generate paging and alerting for the appropriate type of service.
When there is signaling directed to a UT, for example, UT 116, this signaling might not be delivered directly to UT 116 depending on the state of UT 116. If UT 116 is in idle mode, SGSN 122 does not have any information about UT 116; therefore, SGSN 122 will page UT 116 before delivering the signaling. UT 116 might be in a disadvantaged location that normal paging might not be able to reach UT 116.
Methods known in the art notify user in a disadvantaged location by sending a high penetration paging message on a specific channel so that user can move to a better area if the user desires. However, the present methods do not distinguish the traffic type of the incoming call.
The main problem to solve is how to identify the type of incoming call. Since SIP signaling is compressed, SGSN 122 and RAN 120 are not able to identify the traffic class. In order to discuss the procedures to establish a session between two user terminals, Policy Control and Charging (PCC) rules followed by IMS need to be discussed, which is explained with the help of FIG. 2.
FIG. 2 illustrates an example of a typical PCC architecture.
As illustrated in the figure, PCC 200 includes an Application Function (AF) 202, a Policy and Charging Rules Functions (PCRF) 204, a Policy Charging and Enforcing Function (PCEF) 206, an Offline Charging System (OFCS) 208, an Online Charging System (OCS) 210, and a Subscriber Profile Repository (SPR) 212.
Interface between different components in FIG. 2, for example, Rx, Gx, Gy, Gz and Sp, are interfaces based on diameter protocol, which are known in the art and not discussed in this application. Diameter is a signaling protocol that has been specified by Internet Engineering Task Force (IETF) to perform Authentication, Authorization and Accounting (AAA) functions in IP based networks. IMS deploys diameter protocol in most central functionalities and interfaces.
AF 202 and PCRF 204 are part of P-CSCF 132 in this example. When a call or a message from a user, for example, UT 116, reaches P-CSCF 132, it is forwarded to AF 202. AF 202 is operable to determine the type of message, whether it is a phone all or a general broadcast. AF 202 forwards the message to PCRF 204 via Rx interface. PCRF 204 is operable to determine the charging rules for this message. In order to determine the charging rules, PCRF 204 communicates with SPR 212 using Sp interface, which contains the set of rules for each user including what is allowed for a particular user in terms of receiving a call. Based on the information provided by SPR 212, PCRF 204 derives the rules for what can be done with the user including the QoS and classification and forwards it to PCEF 206 via Gx interface.
PCEF 206 is operable to implement the rule derived by PCRF 204 by either allowing the call or blocking the call. PCEF 206 is a part of GGSN 124, which analyzes the user traffic and reports the measured usage to the charging system. For charging, PCEF 206 has support for both standardized charging mechanisms, off-line charging (OFCS 208) and online charging (OCS 210). PCEF 206 communicates with OCS 210 via Gy interface and with OFCS 208 via Gz interface. OCS 210 and OFCS 208 are responsible for billing of the call if the call is allowed. OFCS 208 is operable to provide an off-line charging system, which implies that the charging information does not influence the user or its service until the bill arrives. This methodology is also called post-paid. OCS 210 is operable to provide an on-line charging system, in which the charging information cannot influence the service rendered.
As discussed with reference to FIG. 2, all the components in PCC 200 work together to determine what the call is for, when there is an incoming call, and derive the QoS that is used for paging.
For 3GPP IMS, which uses SIP as signaling protocol, the SIP messages between P-CSCF and the mobile terminal are compressed to save the over-the-air bandwidth. Hence, the traffic type is not visible to GPRS gateway SGSN in the following two conditions: when mobile terminal is in PMM-idle (Packet Mobility Management-idle) mode, the location of UE is not known in the SGSN and paging is initiated to let known the position of UE at the cell level; and, when mobile terminal is in RRC-URA_PCH (Radio Resource Control-UTRAN Registration Area-Paging Channel) mode, SGSN knows about the position of UE, however, UE still does not have resources available so that RAN will hold the signaling coming from SGSN and page UE so that UE can set up the needed resources.
SIP is in charge of handling and establishing the initiation of a session. An SIP message mainly contains three sections detailing the session, timing and media descriptions. A Packet Data Protocol (PDP) context is created for each session initiated, which contains the desired characteristics of the specific session, including the PDP type and the demanded QoS among other parameters. A PDP context can be viewed as a set of information maintained by UT, GSSN and SGSN. It contains a PDP type that identifies the type of Packet Data Network (PDN), the PDP address, QoS information and other session information. Activating a PDP context refers to creating the PDP context at the UT, SGSN and GGSN so that UT can communicate with an entity in PDN using the PDP address maintained in the PDP context.
A secondary PDP context activation allows the subscriber to establish a PDP context with a different QoS profile to the same PDN. A 3GPP feature called Network Requested Secondary PDP Context Activation (NRSPCA), which is based on PCC of 3GPP Release 7 as discussed above, is explained further with reference to FIGS. 3A-3B to understand how NRSPCA can be applied by IMS CN 106 to outgoing or incoming calls.
FIGS. 3A-3B illustrates NRSPCA procedure for incoming calls in MSS 100.
For discussion purposes, let's assume that UT 116 is receiving an incoming call, which in one scenario is initiated by UE 114 via terrestrial mobile network 104. In another scenario, UT 116 may receive a call from telephone 150 through PSTN 148. In both the scenarios, UT 116 receives the call through IMS CN 106, which is using SIP signaling for communication.
A SIP message typically consists of a header and a message body. For 3GPP systems using SIP protocol, SIP message bodies are defined using Session Description Protocol (SDP). Note that the different steps executed in NRSPCA procedure are known in the art, therefore, not discussed in detail.
Step (1) indicates a SIP INVITE containing a SDP message arrives at AF 202 (S302).
Step (2) indicates that SIP INVITE has been received by AF 202 by sending a SIP 100 message (S304).
SDP received by AF 202 contains information about the message, for example, for a voice call it may contain information about vocoder, bandwidth, etc. AF 202 maps those parameters in to QoS (S306), which includes information about bit-rate, traffic class, error-rate, etc., in step (3).
Step (4) indicates that QoS generated by AF 202 is forwarded to PCRF 204 via Rx interface of Diameter protocol (S308).
In step (5), PCRF 204 authorizes the QoS mapping to determine whether the mapping is allowed or not (S310). For example, if the call requires 64 kb/sec and the user is only allowed to use up to 4 kb/sec, the call is rejected.
In step (6), PCRF 204 communicates with SPR 212 via Sp interface to make a profile request for the user in order to validate what is allowed for the user (S312).
SPR 212 sends a response back to PCRF 204 with the user profile via Sp interface (S314) in step (7).
In step (8), if the call is authorized, PCRF 204 forwards the QoS mapping to PCEF 206 via Gx interface of Diameter protocol (S316).
As discussed with reference to FIG. 3A, steps 1-8 for NRSPCA procedure illustrate establishing PCC rules once a session is initiated. Steps 9-20 are discussed below with the help of FIG. 3B.
Step (9) indicates that PCC rules have been enforced and GGSN 124 has all the PCC rules in place. GGSN 124 performs QoS mapping for UT 116 (S318).
GGSN 124 forwards Initiate Secondary PDP context activation to SGSN 122 via Gn interface (S320) in step (10).
In step (11), assuming UT 116 is in RRC-URA_PCH mode, SGSN 122 sends secondary PDP context activation request to UT 116 through RAN 120 (S322).
At RAN 120, since UT 116 is in RRC-URA_PCH mode, request secondary PDP context activation will not be delivered yet so that UT 116 can setup the needed resources. Instead, RAN 120 will page UT 116 (S324) in step (12).
When UT 116 responds to the page, RAN 120 delivers Request secondary PDP context activation to UT 116 (S326) in step (13).
In step (14), When UT 116 receives a request to create secondary PDP context activation, it responds to SGSN 122 by sending secondary PDP context activation (S328).
SGSN 122 creates a PDP context request and forwards it to GGSN 124 (S330) in step (15).
In step (16), GGSN 124 uses Diameter CCR protocol to communicate with PCRF 204 via Gx interface to update request for UT 116 (S332).
PCRF 204 sends an update response back to GGSN 124 using Diameter CCA protocol via Gx interface (S334) in step (17).
GGSN 124 responds to SGSN 122 for create PDP context request via Gn interface (S336) in step (18).
PCRF 204 communicates with AF 202 using Diameter AAA protocol via Rx interface (S338) in step (19), indicating that UT 116 has already answered. AF 202 holds the SIP INVITE.
RAN 120 performs Radio Access Bearer (RAB)/Radio Bearer (RB) setup in order to allocate resources for UT 116 (S340) in step (20).
NRSPCA procedure for incoming calls was discussed with reference to FIGS. 3A-3B. When SIP INVITE with SDP offer arrives at P-CSCF 132, with the destination of UT 116, P-CSCF 132 holds it. P-CSCF 132 then proceeds with NRSPCA procedure. Steps 3-9 discuss the processes until PCC rules are decided and forwarded to PCEF 206. PCEF 206 then sends Initiate secondary PDP context activation to SGSN 122. Assuming UT 116 is in RRC-URA_PCH mode, SGSN 122 sends Request secondary PDP context activation to UT 116 through RAN 120. At RAN 120, since UT 116 is in RRC-URA_PCH mode, Request secondary PDP context activation from SGSN 122 will not be delivered yet. Instead RAN 120 will page UT 116. When UT 116 responds to the page, RAN 120 then delivers the Request secondary PDP context activation. Steps 14-20 show the secondary PDP context activation process until UT 116 receives resource allocations in the form of RAB/RB configuration.
In 3G IMS systems where SIP signaling is used, the information about the type of service is indicated inside the SIP message. However the entities (SGSN, RAN) responsible for paging and alerting cannot read the contents of SIP message since SIP signaling is compressed and/or encrypted by IMS elements before it reaches SGSN and RAN. Hence enhanced paging based on traffic type cannot be done.
There is a need for enhanced paging (alerting) to reach users in disadvantaged location such as in a building. MSS link margins are typically insufficient for paging to reach users in such disadvantaged scenarios. Physical layer waveform along with an increase in satellite power can address this issue from a link budget perspective. However it is desirable that enhanced paging using increased satellite power is only used for traffic type and terminal type.
Many usage scenarios involve connecting one or more external UEs to wireless user terminals (e.g., 3G satellite terminals). Individual UEs establish end-to-end sessions, each requiring different QoS treatments depending on application and data rate. Appropriate QoS treatment in 3G networks (e.g., 3GPP) is provided via establishment of Secondary PDP context between the wireless terminal and core network with the knowledge of application type, data rate etc. However when an external UE generates sessions, the wireless terminal is often unable to deduce the application type and data rate due to encryption and/or compression.
A key attribute of 3G wireless system is the capability to provide differentiated QoS across applications. In order for the system to provide effective QoS differentiation across applications, the 3G system elements have to be made aware of the multiplicity of applications that a user terminal has invoked via secondary PDP contexts with appropriate QoS information elements. As described above, lack of visibility to applications will prevent user terminals from establishing secondary PDP contexts with QoS information elements that are most optimal for the application. For example, when the user terminal does not have the visibility of the application protocol such as Facsimile over IP (FoIP) and Modem over IP (MoIP), appropriate QoS cannot be established for the user terminal.
What is needed is a system and method to provide enhanced paging and optimum QoS for specific service types, in spite of not having visibility to the content of SIP message.